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components  of  the  Tactical  Tomahawk  Weapon  Control  System  (TTWCS),  the  Advanced  Tomahawk 
Weapon  Control  System,  and  a  number  of  key  simulators  used  for  development  and  testing.  Mr. 
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Andrew  Orzechowski 
Abstract 

The  size,  interdependencies,  and  complexity  of  Navy  software  intensive  warfare 
systems  are  continuing  to  rapidly  increase.  Numerous  studies  and  reports  indicate 
that  the  majority  of  DoD/Navy  warfare  system  development  efforts  are  failing  to 
consistently  successfully  deliver  high  quality  software  systems  on  schedule  and 
within  budget.  This  paper  provides  several  examples  of  successful  development 
efforts  that  utilized  Naval  Surface  Warfare  Center  (WC)  in-house  expertise  to 
successfully  deliver  open  architecture  (OA)-based  multi-system  and  multi-platform 
capable  software  systems  with  reusable  components.  This  paper  also  provides 
insight  into  how  government  in-house  software  expertise  can  be  utilized  to  mitigate 
many  of  the  documented  software  system  acquisition  challenges  that  prevent  the 
successful  development  and  delivery  of  high  quality  software  systems  on  schedule 
and  within  budget. 

Introduction 

The  definition  and  goals  of  OA  within  this  paper  means  designing  and  implementing 
software-intensive  systems  that  are  scalable,  reliable,  portable,  maintainable,  modular,  and 
reusable;  and  thereby  lead  to  high  system  quality  while  also  reducing  cost  and  schedule.  As 
shown  in  Figure  1 ,  the  DoD/Navy  is  not  consistently  delivering  high  quality  OA  warfare 
systems  on  schedule  and  within  budget.  This  paper  will  provide  insight  into  how  several 
Navy  software  systems  achieved  the  goals  of  OA  via  the  utilization  of  in-house  software 
expertise. 
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Figure  1.  Typical  Warfare  System  Acquisition  Results 

Current  State:  Development  Approach  and  Results 

This  section  provides  a  high-level  overview  of  the  typical  software  intensive  system 
acquisition  development  approach  and  results. 

In  the  typical  software  system  acquisition  approach,  the  government  leads  the  initial 
identification  of  the  needed  warfighter  capabilities  but  relies  almost  entirely  on  industry 
experts  for  the  system  and  software  architecting,  designing,  and  implementation. 
Government  engineers  do  not  actually  architect,  design,  nor  develop  any  of  the  actual 
system  and  software  components.  Government  insight  into  the  architecture,  design,  and 
implementation  is  provided  by  a  few  software  SMEs  that  participate  during  the  reactionary 
(vice  proactive)  process  of  peer  and  milestone  reviews.  Following  the  system  design  and 
development  performed  by  industry,  the  government  then  leads  the  system  testing  and 
certification  efforts  with  industry  being  responsible  for  assessing  and  resolving  problems 
found  during  system  testing.  The  frequent  unsuccessful  results  of  this  acquisition  approach 
are  well  documented  in  reports  from  organizations  such  as  the  Defense  Science  Board 
(DSB)  and  the  Government  Accountability  Office  (GAO).  Figure  1  reports  the  following 
statistics: 


■  In  2002,  the  DSB  Task  Force  on  Defense  Software  reported  that  only  16% 
are  completed  on  schedule  and  within  budget;  31%  of  programs  are 
cancelled;  53%  of  the  programs  remaining  have  cost  growth  greater  than 
89%;  and  the  average  final  product  includes  only  61%  of  the  original  intended 
features. 

■  In  2004,  the  GAO  reported  that  the  DoD  spent  40%  of  its  software 
development  budget  reworking  software  because  of  quality  related  issues 
(GAO-04-393,  March  2004). 

■  In  2008,  the  DSB  reported  that  the  majority  of  DoD  weapons  systems  are 
failing  Initial  Operational  Testing. 

■  In  2009,  Senator  Carl  Levin  reported  that  since  2006  nearly  half  of  DoD’s 
largest  acquisition  programs  have  exceeded  Nun-McCurdy,  and  that  95  major 
defense  programs  have  had  their  acquisition  costs  grow  by  an  average  of 
26%  and  have  experienced  an  average  schedule  delay  of  almost  two  years. 
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Future  State:  Challenges  and  Improvement  Goals 

Figure  2  summarizes  some  of  the  key  challenges  and  improvement  goals  for 
software  intensive  warfare  system  acquisition  programs.  The  primary  challenge  is  to 
consistently  successfully  deliver  high  quality,  secure  and  safe  software  intensive  weapon 
systems  that  fully  meet  the  needs  of  the  warfighter.  Achieving  OA  systems  will  improve 
system  quality,  promote  competition  and  innovation,  and  thereby  reduce  cost  and  schedule. 
Achieving  OA  systems  and  benefits  is  complicated  by  having  to  integrate  rapidly  evolving 
system  and  software  technologies  into  existing  large  complex  systems  composed  of  varying 
levels  of  legacy  technology  while  maintaining  Information  Assurance  (IA).  As  demonstrated 
by  the  success  examples  in  the  next  section,  one  approach  to  meet  these  software  system 
acquisition  improvement  goals  is  to  utilize  in-house  experts  with  the  applied  system  and 
software  engineering  technical  expertise,  experience,  and  corporate  knowledge  required  to 
successfully  team  with  industry  to  achieve  non-proprietary  OA  systems. 


Figure  2.  Challenges  and  Improvement  Goals 

Warfare  System  Development  Success  Examples 

This  section  will  provide  several  examples  of  software  system  development  efforts 
that  have  resulted  in  high  quality  multi-platform  capable  systems  with  reusable  components 
that  have  been  consistently  delivered  within  cost  and  schedule  constraints.  The  common 
and  significant  contributing  factor  to  the  success  of  these  warfare  system  development 
efforts  is  that  government  technical  subject-matter  experts  were  responsible  for  actually 
leading  and  developing  some  of  the  critical  requirements,  architecture,  design,  and  software 
elements  of  these  systems.  Utilization  of  government  expertise  has  been  consistently 
successfully  utilized  by  the  Naval  Surface  Warfare  Center  Dahlgren  Division  (NSWCDD)  for 
various  strategic  and  tactical  warfare  systems.  NSWCDD  government  software  engineers 
have  been,  and  still  are,  responsible  for  the  architecting,  designing,  coding  and  testing  of 
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many  of  the  most  critical  and  complex  (e.g.  safety  critical,  real-time,  complex  algorithms) 
software  components.  The  successful  utilization  of  warfare  center  in-house  experts  has 
been  utilized  in  various  system  development  approaches  that  include: 

■  teaming  with  industry  as  part  of  an  integrated  system  development  team, 

■  prototyping  and  development  of  the  initial  engineering  development  module, 
and 

■  rapid  development  and  delivery  of  reusable  architectures  or  components. 

The  following  specific  success  examples  of  the  different  uses  of  in-house  expertise 
are  provided  in  the  next  sections: 

■  Tomahawk  Cruise  Missile  Weapon  Control  System  (TTWCS), 

■  Generic  Data  Extraction,  Analysis  and  Reduction  (GeDEAR)  Framework,  and 

■  Cooperative,  Communications,  Control  Core  Engagement  (4CE)  framework 
for  the  Full  Spectrum  Effects  Package  (FSEP)  and  Gunslinger  Package  for 
Advanced  Convoy  Security  (GunPACS)  sniper  sense,  track,  and  engage 
systems. 

The  previously  mentioned  development  efforts  successfully  achieved  the  following: 

■  delivered  reliable,  maintainable,  scalable  and  reusable  architectures,  design, 
and  code  that  provide  multi-platform  and/or  multi-system  capability. 

■  successfully  integrated  a  mix  of  legacy  components,  new  commercial-off-the- 
shelf  (COTS)  components,  and  government  engineer  developed  reusable 
architectures  and  components,  while  maintaining  Information  Assurance  (IA). 

■  successfully  met  complex,  real-time,  safety  critical  functional  requirements 
and  the  associated  challenging  Key  Performance  Parameters  (KPPs). 

■  maintained  government  corporate  knowledge  and  control  of  the  system 
architecture,  design,  and  technology. 

■  maintained  government  applied  technical  expertise  with  current  and  emerging 
system  and  software  technologies,  methodologies,  processes,  and  tools. 

■  delivered  these  systems  on  schedule  and  within  budget. 

Success  Example  1:  Tomahawk  Cruise  Missile  Weapon  Control  System  (TTWCS) 

The  Tomahawk  Cruise  Missile  system  has  performed  exceptionally  well  in  thousands 
of  operational  events,  and  as  noted  in  the  2004  GAO  report  on  Defense  acquisition,  the 
Tomahawk  Cruise  Missile  program  was  cited  as  one  of  the  few  successful  DoD  warfare 
system  acquisition  programs. 

The  current  Tomahawk  Cruise  Missile  system  is  composed  of  three  major  segments: 
the  Tomahawk  Command  and  Control  System  (TC2S),  The  Tactical  Tomahawk  Weapon 
Control  System  (TTWCS),  and  the  All-Up-Round  (the  missile).  The  TTWCS  segment  is 
developed  by  an  integrated  government  and  industry  development  team.  This  integrated 
team  approach  has  been  successfully  utilized  since  the  early  1980s  and  is  still  employed 
today.  The  government  and  industry  integrated  development  team  (IDT)  has  succeeded  in 
developing  common  reusable  software  components  to  support  multiple  Tomahawk  firing 
platforms  (United  States  submarine  and  surface  ship  variants,  as  well  as  United  Kingdom 
Royal  Navy  submarines).  As  shown  in  Figure  3,  the  government  engineers  architected, 
designed,  developed,  and  delivered  the  multi-platform  capability  via  object-oriented  design 
and  implementation  techniques  at  the  Object/Class  Level  within  one  of  the  major  TTWCS 
Computer  Software  Configuration  Items  (CSCIs). 
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Over  the  past  several  decades,  the  TTWCS  IDT  has  consistently  successfully  delivered 
software  upgraded  to  incorporate  and  integrate  the  latest  technologies.  Examples  include 
the  evolution  from  Mil-spec  processors  (ROLM  1666)  to  modern  processors  (HP744,  X86), 
from  mil-spec  operating  system  (RMX/RDOS)  to  open  system  OS  (LINUX),  and  from  first 
generation  programming  languages  (Assembly,  Fortran)  to  modern  languages  (Ada,  Java, 

C,  C++).  The  design  approach  taken  by  the  IDT  has  resulted  in  the  development  of  a 
common  baseline  of  TTWCS  software  that  is  installable  on  all  platform  variants.  This 
approach  significantly  reduces  the  amount  of  software  code  that  must  be  maintained  over 
the  lifecycle  of  the  product,  resulting  in  a  reduced  number  of  defects  delivered  to  the  fleet 
and  a  significant  reduction  in  out-year  sustainment  costs. 

The  IDT  has  successfully  incorporated  new  system/software  development 
methodologies  including  the  transition  from  functional  design  to  object-oriented  design,  from 
waterfall  development  to  spiral/increment  development;  from  human-only  generated  coding 
to  graphic-user-interface  and  auto-code  generation  tools,  and  from  point-to-point  interfaces 
to  FDDI/ETHERNET  H/W  employing  IP-based  communications  using  Service  Oriented 
Architecture  standards. 

The  TTWCS  IDT  has  achieved  and  demonstrated  OA  design  and  implementation.  As 
shown  in  Figure  3,  the  TTWCS  government  software  engineers  utilized  object-oriented 
design  to  achieve  scalability  and  reusability  with  regards  to  the  goal  of  easily  interfacing  with 
multiple  platforms  and  their  unique  launching  systems.  The  TTWCS  has  been  easily 
upgraded  to  support  not  just  U.S.  surface  ship  vertical  launching  systems,  but  also  U.S. 
submarine  and  United  Kingdom  Royal  Navy  submarine  platforms.  As  the  TTWCS  has  been 
upgraded  to  interface  with  the  new  platform  launching  systems,  the  government  software 
engineers  were  able  to  define  the  software  requirements  and  architecture,  document  the 
design  modifications,  implement  and  perform  software  level  testing  for  the  associated  new 
launcher  interface  typically  within  a  year  timeframe.  Reuse  of  existing  software  objects  from 
the  TTWCS  software  have  been  successfully  integrated  into  new  launching  system 
software  components  contributing  to  reduced  development  time  and  reduced  cost.  The 
Navy’s  new  surface  combatant  (Zumwalt  Class  Destroyer)  is  employing  the  above 
mentioned  approach  to  integrate  Tomahawk  capability  on  that  platform  type. 

For  nearly  30  years,  the  development  team  responsible  for  the  Tomahawk  Weapon 
Control  System  has  successfully  met  interdependency  deliveries  and  provided  the  fleet  with 
a  reliable,  high-quality  product.  The  software  quality  of  the  TTWCS  software  has  been 
consistently  high  with  the  integrated  software  for  currently  deployed  systems  averaging 
approximately  one  Defect/KSLOC,  which  compares  favorably  with  available  industry  data. 
The  TTWCS  software  developed  by  the  government  and  industry  team  has  consistently  met 
all  Key  Performance  Parameters  (KPP)  identified  in  its  Operational  Requirements  Document 
(ORD)  and,  most  important,  has  performed  exceptionally  well  in  tactical  operations. 
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Figure  3.  Tomahawk  Multi-Platform  Design 

Success  Example  2:  Generic  Data  Extraction,  Analysis  and  Reduction  (GeDEAR) 

The  GeDEAR  effort  is  an  example  of  a  software  component  that  was  successfully 
architected  and  implemented  entirely  by  in-house  experts  to  be  easily  integrated  and  utilized 
within  different  programs  and  systems.  The  GeDEAR  framework  has  proven  to  reduce  cost 
and  schedule  by  providing  a  robust  utility  for  quickly  identifying  the  root  cause  of  defects. 

GeDEAR 

■  allows  for  integration  of  a  software-based  data  extraction  capability  into  a 
system  with  minimum  cost  or  schedule  impacts; 

■  works  across  many  different  data  formats  and  interfaces  through  the  use  of 
plug-ins; 

■  supports  a  wide  range  of  platforms  and  operating  systems; 

■  provides  a  foundation  for  common  data  extraction,  reduction,  and  analysis 
tools;  and 

■  is  freely  available  on  forge.mil. 

Figure  4  provides  the  architecture  of  GeDEAR,  which  enables  users  to  utilize  all  or 
any  of  the  three  major  components  (Management  Console,  Extraction  Server,  and 
Reduction  Program)  to  provide  an  integrated  data  extraction  and  analysis  capability  within 
their  tactical,  training  or  test  system  and  software.  GeDEAR  utilized  open  architecture 
design  to  eliminate  hardware,  operating  system  dependencies,  interface  dependencies,  and 
utilizes  a  plug-in  design  to  enable  users  to  quickly  integrate  and  tailor  the  GeDEAR  utility  to 
meet  the  specific  needs  of  the  given  system. 
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Computer  A  Computer  B 


■vent  Output 


Figure  4.  GeDEAR  Multi-System  Design 

To  date,  the  government  expert  developed  GeDEAR  component  has  been  quickly, 
easily,  and  successfully  integrated  into  the  following  systems: 

■  Tomahawk  Weapon  Control  System  (TWCS):  4  Week  Effort.  TWCS  is  an 
existing  system  and  incorporated  only  the  Reduction  Program  component  of 
GeDEAR.  The  use  of  GeDEAR  required  the  development  of  several  plug-ins 
to  the  Reduction  Program  to  modify  the  output  of  the  reduced  data  and  a 
small  program  that  converted  the  file  that  describes  how  the  events  are 
structured  from  their  legacy  format  to  the  GeDEAR  format. 

■  Ship  Protection  System  (SPS):  3  Month  Effort.  SPS  was  a  new  development 
effort  and  incorporated  the  entire  GeDEAR  framework.  The  use  of  GeDEAR 
required  the  development  of  a  plug-in  to  the  Extraction  Server  to  allow  it  to 
automatically  capture  DDS  traffic  on  the  network  and  extract  this  information. 

■  Advanced  Multi-Configuration  Environment  Simulator  (AMES):  1  Month 
Effort. 

■  AMES  is  an  existing  system  and  incorporated  the  entire  GeDEAR  framework. 
The  use  of  GeDEAR  required  the  modification  of  how  events  were  being 
extracted  within  tactical  software  and  the  updating  of  event  definition  files. 

Success  Example  3:  Cooperative,  Communications,  Control  Core  Engagement  (4CE) 
Framework 

4CE  is  an  example  of  utilizing  government  expertise  and  resources  to  rapidly 
develop  and  delivery  critical  systems  to  the  warfighter.  4CE  is  an  example  of  a  successful 
OA  based  multi-platform  and  multi-system  software  framework.  Government  engineers  have 
teamed  with  industry  to  utilize  agile  software  development  methodology  to  successfully 
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deliver  the  integrated  sensor  and  weapon  capabilities  for  Marine  Corps  and  Army  vehicles 
such  as  Gunslinger,  Full  Spectrum  Effects  Platform  (FSEP),  and  Wolfpack. 

This  integrated  agile  development  team  has  also  been  utilized  for  the  Naval 
Expeditionary  Overwatch  (NEO)  Intelligence,  Surveillance,  and  Reconnaissance  (ISR) 
systems.  These  rapid  development  efforts  were  led  by  government  engineers  who  quickly 
assessed  and  integrated  multi-vendor  hardware  and  software  technologies  to  provide  the 
deployed  warfighters  with  much-needed  capabilities  that  met  emergent  mission  critical 
needs  for  the  Navy,  Marine  Corps  and  Army. 

This  framework  and  its  precursors  have  been  used  to  deploy  several  vehicles  to  Iraq 
and  soon  Afghanistan.  The  Gunslinger  vehicle  deployed  to  Iraq  for  eight  months.  The  three 
FSEP  vehicles  were  deployed  to  Iraq  in  January  2007  and  two  are  still  in  operation. 
GunPACS’  four  vehicles  will  deploy  this  year  to  Afghanistan.  The  urgent  need  for  these 
systems  made  it  necessary  to  produce  these  systems  in  a  year  or  less.  Therefore, 
minimizing  redundant  effort  became  of  utmost  importance. 

Despite  developing  systems  for  various  military  Services  and  vehicle/vessel 
platforms,  there  were  many  opportunities  for  code  reuse  and  architecture  abstraction. 
Regardless  of  the  program  sponsor  or  user,  all  systems  were  encapsulated  into  three  layers 
of  abstraction,  which  are  as  follows: 


■  Presentation  Layer — GUI,  mapping  engine,  and  video  situational  awareness. 

■  Middle  Layer — behaviors,  algorithms,  and  logic. 

■  Hardware  Layer — interface  with  COTS  and  GOTS  hardware. 


As  shown  in  Figure  5,  the  4CE  framework  was  developed  to  enable  the  reuse  of 
these  three  layers.  It  was  also  developed  to  enable  the  fast  integration  of  new  sensors  into 
the  hardware  layer.  In  the  past,  integrating  a  new  sensor  could  take  two  to  three  months 
since  software  developers  had  to  significantly  modify  code  through  all  three  layers. 
However,  with  the  use  of  standard  interfaces  between  layers  and  modularization,  sensor 
integration  was  reduced  to  weeks  and  in  some  cases  just  a  few  days.  The  4CE  framework 
now  provides  a  common  software  platform  for  all  rapid  integration  projects. 


Presentation  Layer 


Hardware  Layer 


Plug-In  Framework 

Acoustic  Shot  ]  Optical  Non-Lethal  Weapon  Mount 

Detection  Interface  Interface  Interface 


Boomerang 

Plug-In 
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Plug-In 

L  ^ 

Figure  5.  4CE  Multi-Platform  Multi-System  Architecture 


The  value  of  this  common  software  platform  includes 
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■  increased  code  reuse, 

■  improved  quality, 

■  shortened  development  cycle, 

■  rapid  integration,  and 

■  efficient  developer  resource  utilization. 

As  shown  in  Figure  6,  the  single  greatest  benefit  of  the  4CE  framework  is  the  ability 
to  deliver  more  capability  for  less  cost  and  time.  This  agile  software  development  team,  in 
its  early  days,  would  surge  to  as  many  as  17  developers  and  a  development  duration  of 
around  one  year.  Conversely,  as  the  4CE  framework  matured,  software  development  could 
be  characterized  as  a  2-4  person  team  working  for  3-6  months. 

The  value  of  this  architecture  and  model  for  rapid  integration  and  deployment  has 
been  further  proven  with  the  Command  Control  Module  (C2M)  project.  NSWCDD  will  be 
developing  a  Technical  Data  Package  and  partner  with  industry  to  produce  -750  counter¬ 
sniper  systems  for  the  Army.  In  a  possible  second  phase  NSWCDD  will  team  with  an 
industry  partner  to  produce  another  -2000  systems. 
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Figure  6.  4CE  Reduced  Development  Time  and  Resources 

As  shown  in  Figure  7,  the  next  stage  in  the  evolution  of  4CE  is  to  increase  its  open 
architecture  characteristics  and  transition  to  a  service-oriented  architecture  (SOA)-based 
system.  Moving  to  a  SOA  will  separate  capabilities  and  functions  into  services  provided 
over  a  bus.  In  the  current  state  of  4CE  it  is  possible  to  compete  out  hardware  plug-ins  for 
new  sensors.  The  transition  to  the  SOA  based  arch  will  facilitate  the  plug-in  and  third-party 
integration  in  the  Middle  Application  and  Presentation  Layers. 
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Figure  7.  Future  4CE  Architecture 

Key  Factor  for  Warfare  System  Development  Success 

A  key  factor  in  the  previous  success  examples  was  the  applied  knowledge  of  the 
government  SMEs  at  the  lowest,  most  detailed  levels  of  system  abstraction.  Although 
software  has  evolved  into  one  of  the  most  significant,  complex,  and  critical  elements  of 
mission  critical  systems,  the  typical  DoD/Navy  acquisition  strategy  tends  to  treat  the 
software  components  as  black  boxes  with  the  internal  software  architecture  and  design 
development  (and  detailed  understanding)  left  almost  entirely  in  the  hands  of  private 
industry  SMEs.  Figure  8  depicts  a  typical  software  intensive  system  with  hundreds  of  system 
level  requirements,  interfaces,  and  components.  This  same  system  decomposed  at  the 
software  level  may  include 

■  hundreds  to  thousands  of  software  level  requirements, 

■  hundreds  to  thousands  of  internal  and  external  software  interfaces, 

■  hundreds  to  tens  of  thousands  computer  software  components  (CSCs), 

■  thousands  to  tens  of  thousands  internal  software  interfaces  and  interactions, 

■  millions  to  hundreds  of  millions  of  logic  threads,  and 

■  millions  to  hundreds  of  millions  of  source  lines  of  code  (SLOC). 


ACQUISITION  RESEARCH:  CREATING  SYNERGY  FOR  INFORMED  CHANGE  - 197 


SYSTEM  COMPONENTS 


Government  technical  insight  only  at 
the  system  level  components  is 
insufficient  to  ensure  successful  SW 
intensive  system  acquisition 


Government  must  maintain  applied 
expertise  and  insight  at  the  SW 
level  of  components  in  order  to 
ensure  successful  SW  acquisition 


Figure  8.  System  and  Software  Complexity 

The  current  typical  acquisition  approach  often  limits  the  government’s  technical 
understanding  to  a  few  pages  of  high  level  system  and  software  architecture  diagrams.  The 
government  understands  and  “controls”  the  interfaces  between  the  software  components 
only  at  the  highest  level  of  system  abstraction.  There  is  often  limited  government  in-depth 
understanding  of  the  architecture,  design,  and  implementation  of  the  software  level 
components.  The  government  SMEs  are  limited  to  participation  via  milestone  review  events 
(e.g.,  Requirement  Reviews,  Design  Reviews,  Test  Readiness  Reviews,  etc.).  Limiting 
government  SME  to  just  oversight  roles  and  only  milestone  review  event  participation  is 
ineffective  for  ensuring  that  the  software  components  and  artifacts  fully  meet  the  OA 
objectives  of  modularity,  scalability,  reliability,  maintainability,  and  quality,  it  does  not  ensure 
that  the  implementation  artifacts  (i.e.,  code)  and  design  artifacts  remain  consistent  with  each 
other. 

As  demonstrated  by  the  success  examples  in  the  previous  section,  government  and 
industry  technical  teams  can  be  successful.  Under  this  alternative  acquisition  approach,  the 
government  engineers  serve  as  the  technical  lead  for  critical  components,  which  includes 
being  responsible  for  not  just  assessing  industry  developed  architecture,  design,  and  code 
artifacts,  but  actually  developing  a  subset  of  the  artifacts.  The  artifacts  (requirement  specs, 
design  documents,  code,  etc.)  are  developed  by  integrated  government  and  industry 
software  development  teams  that  utilize  cross-organizational  design/code  peer  reviews  to 
ensure  high-quality  products  and  conformance  to  best-practices.  Government  system, 
software  and  test  SMEs  are  responsible  for  developing  and  delivering  a  subset  of  the 
mission  critical  tactical  system  and  software  components  and  the  associated  technical 
artifacts,  including  requirements  specifications,  architecture,  and  design  and  interface 
documents,  code,  and  test  procedures. 

The  government  software  development  engineers  have  the  same  expectations  and 
requirements  relative  to  cost,  schedule,  and  technical  performance  as  their  industry  peers. 
The  government  SMEs  are  also  responsible  for  providing  the  critical  management  products 
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as  well  including  development  process  documents,  metrics,  schedules,  progress  indicators, 
interdependencies,  and  risks.  This  is  required  to  develop  and  maintain  in-house  SMEs  with 
the  applied  technical  and  programmatic  experience  required  to  be  able  to  both  successfully 
develop  the  system  components  and  manage  (accurately  estimate  and  track  cost,  schedule, 
and  risk)  the  development  effort  at  all  levels  of  the  system  decomposition  (functional 
domain,  component,  segment,  CSCI,  and  down  to  the  CSCI  sub-component  object  and 
class  level).  The  following  elements  are  critical  for  enabling  success: 

■  A  common  set  of  industry  and  government  processes  and  expectations, 

■  Well-defined,  documented  and  maintained 

o  roles  and  responsibilities;  system  development  processes  and 
metrics;  cost,  schedule,  and  performance  expectations;  Integrated 
Master  Schedule  (IMS);  interdependency  products  and  associated 
delivery  dates;  and  risk  management. 

■  Proactive  integrated  management  of  cost,  schedule  and  performance. 

■  Government  test  team  is  independent  from  the  government  development 
team. 

■  Milestone  reviews  that  include  independent  competency  experts. 

■  Frequent  (daily)  and  structured  open  team  communication. 

Integrated  Government  and  Industry  Development  Team  Benefits 

This  section  describes  the  benefits  of  utilizing  the  expertise  still  available  at  the  Navy 
Warfare  Centers  as  part  of  a  government  and  industry  software  intensive  system 
development  team.  This  alternative  approach  benefits  the  System  Program  Offices,  the 
Industrial  Base,  and  the  warfighter. 

In  2008,  the  ASN/RDA  Software  Process  Improvement  Initiative  (SPII)  Software 
Acquisition  Management  (SAM)  focus  team  published  a  report  that  described  the  following 
critical  problems  that  apply  to  the  vast  majority  of  DoD/Navy  software  intensive  system 
program  acquisition  offices: 

■  lack  of  effective  management, 

■  immature  acquirer  (program  offices), 

■  ineffective  requirements  management, 

■  high  personnel  turnover, 

■  unrealistic  cost  and  schedule  estimates, 

■  ineffective  utilization  of  Earned  Value  Management  System  (EVMS)  for 
software,  and 

■  failure  to  utilize  lessons  learned. 

The  utilization  of  in-house  technical  expertise  has  been  demonstrated  to  mitigate  the 
problems  mentioned  previously  and  provide  the  following  benefits  to  the  program  offices: 

Program  offices  will  have  access  to  in-house  experts  with  the  technical  and 
acquisition  process  experience  to  aid  the  program  offices  in  successfully  managing  the 
integrated  government  and  industry  development  teams. 

■  The  in-house  experts  will  have  the  applied  knowledge  to  assess  industry 
technical  approaches  and  also  their  software  development  processes.  This 
includes  having  in-house  experience  and  historical  metrics  from  system  and 
software  cost  and  schedule  estimates  and  will  be  able  to  provide  support  for 
independent  cost  and  schedule  assessments. 


ACQUISITION  RESEARCH:  CREATING  SYNERGY  FOR  INFORMED  CHANGE  - 199 


■  The  in-house  experts  will  have  applied  experience  developing  and 
implementing  system  requirements  at  all  levels,  which  will  enable  them  to 
support  program  office  requirement  management  and  volatility  risk  reduction. 

■  The  government  engineers  will  have  in-depth  knowledge  of  various  weapon 
system  architectures  and  maintain  the  corporate  knowledge  required  to 
mitigate  the  risk  of  program  office  leadership  and  personnel  turnover,  as  well 
as  changes  in  the  industry  development  organizations. 

■  The  in-house  engineers  will  have  applied  experience  with  EVMS  and  can  aid 
the  program  offices  in  setting  up  realistic  and  meaningful  based  software 
EVMS  processes  and  tools. 

■  By  maintaining  engineers  with  applied  experience  in  both  previous  and 
current  complex  development  efforts,  the  program  offices  will  have  a  source 
of  objective  lessons  learned  and  metrics  that  can  be  applied  to  future 
development  process  improvement. 

■  Maintaining  a  team  of  in-house  experts  provides  the  program  office  with 
leverage  over  the  contractor  if  the  contractor  is  failing  to  meet  program  cost, 
schedule,  or  technical  performance  requirements.  The  program  office 
leadership  will  have  the  option  to  augment  the  industry  software  team  with 
on-site  government  software  engineers,  or  transfer  the  responsibility  for 
software  component  development  from  industry  to  government.  This  can  be 
accomplished  easily  as  the  government  software  engineers  are  part  of  the 
software  development  team  from  the  beginning.  There  will  be  no  need  to 
perform  a  costly  re-competition  to  assign  the  work  to  another  private  industry 
team  that  would  be  unfamiliar  with  the  program  requirements  and  plan. 

■  Maintaining  an  experienced  government  software  development  organization 
mitigates  the  impact  of  program  office  leadership  changes.  Acquisition 
program  office  leadership  transition  may  occur  at  any  point  during  the  system 
development  effort.  The  system  development  organizations  are  faced  with 
the  challenge  of  still  meeting  the  previously  defined  development  milestones 
and  delivery  dates,  while  simultaneously  changing  organizational  structures, 
reporting  chains  of  command,  tasking  priority  changes,  funding  reallocations, 
and  development  process  changes  directed  by  the  new  leadership.  The 
experienced  government  development  team  can  provide  the  following 
benefits  to  the  acquisition  office’s  new  leadership: 

o  Maintains  critical  corporate  knowledge  in  order  to  aid  the  new 
leadership  in  quickly  coming  up  to  speed  on  the  history  of  the 
program,  the  system’s  architecture  and  functionality,  the  various 
development  organization’s  roles  and  responsibilities,  current 
development  process,  and  status  of  the  current  development  efforts 
(schedule,  progress,  and  risk). 

o  Provide  impact/risk  assessment  for  new  organizational  or  process 
changes. 


Senior  DoD/Navy  system  acquisition  leaders  have  expressed  the  need  to 
reconstitute  and  maintain  in-house  technical  expertise.  The  government  cannot  attract  the 
best  talent,  nor  sustain  highly  motivated  and  high-quality  SMEs  by  limiting  their  tasking  to 
looking-over-the-shoulders  of  industry  engineers.  By  assigning  actual  system  and  software 
development  responsibility  to  in-house  engineers,  the  government  can  reconstitute  and 
maintain  the  software  expertise  pipeline,  as  shown  in  Figure  9,  and  thereby  develop  the 
senior-level  expertise  required  to  perform  as  technical  and  programmatic  peer  level 
teammates  with  industry. 
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Gov’t  hands-on  software  development  is  required  to: 

•Maintain  expertise  with  the  latest  software  technologies 
•Attract  the  best  software  engineers 

•Serve  as  a  smart  buyer  and  successfully  team  with  industry 


Complexity 

and 

Level  of  Responsibility 


In-House  Software  Subject  Matter  Experts 


SOS  AND  COMPLEX  SYSTEM  LEVEL 

-Architect  and  Design  Complex  Systems 
-Assess  and/or  Provide  Technology  Approaches 
-Assess  and/or  Provide  Cost  and  schedule  Estimates 
-Serve  as  Software  Technical  Authority 


Segment  and  Component  Level 


Computer  SW  Configuration  Item  (CSCI)  Level 


Technical  Assignment 
Loop-Back 


SW  Sub-Components 


Time 


Figure  9.  Government  Expertise  Pipeline 

The  successful  systems  described  in  the  previous  section  assign  government  SMEs 
responsibility  for  software  architecture,  design,  code,  and  test  responsibility  and  thereby  are 
able  to  consistently  achieve  the  following: 

■  Maintain  awareness  and  expertise  in  modern  software  technologies  and 
methodologies  necessary  to  understand  and  determine  when/if/how  these 
new  technologies  should  be  utilized. 

■  Successfully  designing  and  implementing  truly  OA  systems  that  fully  meet  the 
goals  of  standardized  interfaces,  scalability,  reliability,  portability,  modularity, 
and  reusability;  thereby  leading  to  higher  system  quality  while  also  reducing 
cost  and  schedule. 

■  Successfully  integrating  the  complex  mix  of  legacy  software  components, 
new  COTS  software  and  hardware  components  and  DoD/Navy  developed 
highly  specialized  software  components  to  provide  integrated  net-centric 
systems  that  can  execute  as  systems-of-systems  and  fully  meet  mission-level 
objectives  and  KPPs. 

■  Successfully  assessing  and  rapidly  integrating  the  most  advanced  software 
technologies  and  methodologies  into  the  software  development  processes, 
environments,  and  systems. 

Strengthening  the  government  in-house  SME  also  benefits  the  industrial  base,  as 
industry  will  have  a  smarter  buyer  of  warfare  systems,  which  enables  the  following: 

■  The  government  will  have  technical  SMEs  with  the  continuing  corporate 
knowledge  and  system  expertise  to  provide  industry  with  better  requirements 
to  enable  more  accurate  cost/effort  responses  to  Requests  For  Proposals 
(RFP). 

■  The  in-house  SMEs  will  be  better  able  to  assess  industry  technical  and  cost 
proposals.  Contacts  will  be  awarded  on  true  best  value  (not  just  the  lowest 
bid).  The  SMEs  will  have  the  expertise  to  validate  that  a  contractor’s  higher 
cost  is  fair  and  value  added  as  the  technical  and  development  processes 
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reflect  current  best-practices  and  meet  the  goals  of  non-proprietary  OA  based 
development. 

■  During  development,  the  industry  SMEs  will  have  peer  government  SMEs 
that  work  proactively  (versus  reactively  via  just  milestones  reviews)  to  ensure 
sound  technical  approaches  and  acceptable  technology/programmatic  risk 
identification  and  mitigation.  The  government  SMEs  will  have  in-depth 
understanding  and  early  insight  into  industry  design/implementation  to  enable 
early  risk  identification  and  mitigation  (e.g.,  accurately  assess  Technology 
Readiness  of  industry  technical  approaches). 

■  The  resulting  increase  in  quality  and  reduction  of  schedule/cost  failures  will 
increase  industry  profit  by  enabling  the  team  to  spend  dollars  on  new 
capabilities  and  production  versus  fixing  significant  numbers  of  defects. 

■  The  government  SMEs  will  have  an  understanding  and  control  of  the 
overarching  system  architecture  and  resulting  system  artifacts  and  thereby 
enable  an  approach  of  contracting  out  smaller  system  components.  This 
promotes  more  competition  and  enables  smaller  businesses  to  obtain 
contracts. 

■  Most  important,  this  alternate  approach  has  proven  to  better  meet  the  needs 
of  the  warfighter  by  providing  high  quality  and  reliable  systems  that  meet  the 
warfighter’s  needs. 

Summary/Recommendations 


Figures  10  and  1 1  summarize  the  typical  and  alternative  system  acquisition  and 
development  approaches,  respectively. 


Figure  10.  Typical  Acquisition  Responsibilities 
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Alternative  Software  Acquisition  Responsibility 


DEFINE  DESIGN 

Needs  System 


DEVELOP  TEST 

System  System 


% 


Gov 


Gov 


Ind 


Gov 


RESULTS:. 

•  Open  Architected  Systems 

•  Non-proprietary  systems 

•  Manageable  cost  variances 

•  Manageable  schedule  variances 

•  Maximized  capabilities 

•  High  quality  software 


Figure  11.  Alternative  System  Acquisition  Responsibilities 

As  directed  in  the  2008  Mr.  Donald  Winter  SECDEF  memo, 

This  combination  of  personnel  reductions  and  reduced  RDT&E  has  seriously 
eroded  the  Department's  domain  knowledge  and  produced  an  over-reliance  on 
contractors  to  perform  core  in-house  technical  functions.  This  environment  has 
lead  to  outsourcing  the  "hands-on"  work  that  is  needed  in-house,  to  acquire  our 
nation’s  best  science  and  engineering  talent  and  to  equip  them  to  meet  the 
challenges  of  the  future  Navy.  In  order  to  acquire  DON  platform  and  weapon 
systems  in  a  responsible  manner,  it  is  imperative  the  DON  maintain  technical 
domain  expertise  at  all  levels  of  the  acquisition  infrastructure. 

The  common  critical  factor  in  the  success  of  the  development  efforts  described  in 
this  paper  was  the  utilization  of  government  technical  SMEs  with  hands-on  expertise  and 
development  responsibilities. 

The  DoD/Navy  must  re-assume  leadership  of  the  system  and  software  architecture 
and  design.  Government  software  architecture  and  technical  authority  must  be 
demonstrated  not  just  at  the  highest  system  composition  level  but  must  extend  down  into 
detailed  software  component  levels  as  well.  In  order  to  attract  and  keep  the  best  and 
brightest  SMEs,  the  government  must  offer: 

■  challenging  development  and  leadership  responsibilities,  and 

■  opportunities  of  architecting,  designing,  and  implementing  solutions  to 
complex  system  functional  capabilities  and  problems  that  address  warfighter 
needs. 

The  DoD/Navy  should  increase  the  utilization  of  integrated  government  and  industry 
technical  development  teams  in  order  to  develop  truly  open  architected  systems  and  thereby 
achieve  the  goals  of  delivering  the  warfighter  with  high-quality  systems  on  schedule  and 
within  budget. 
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Surface  Warfare  Centers 

Addressing  Challenges  and  Improvement  Goals 


♦  Current  State  Approach  and  Results 

♦  Future  State  Challenges  and  Goals 

♦  Surface  V\£irfare  Center  Success  Examples 

♦  Keys  to  Success 

♦  Reconrnendations 

♦  Summary  /  Benefits 
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Current  State 

Typical  System  Acquisition  Approach  and  Results 


Government  relies  primarily  on  industry  for  system  architecture,  design,  and  development. 
Majority  of  programs  experience  cost,  schedule  and  technical  performance  failures. 


References 

•  2000  Defense  Science  Board  Report  and  2004  General  Accounting  Office  Report 

•  2009  Senator  Carl  Levin  Opening  statements  to  Senate  Armed  Service 
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Surface  Warfare  Centers:  In-House  Software  Expertise 
Success  Examples 


♦  Utilization  of  Government  in-house  Software  Expertise 

-  Integrated  Government  and  Industry  Software  development  Teams 

-  System  Prototyping  and  Engineering  Development  Model  development 

-  Rapid  Development  efforts 

-  Reusable  components 

♦  Example  of  Successful  Programs/Projects 

-  Tomahawk  Cruise  IVSssile  V\feapon  Control  System  (TTAAGS) 

-  Generic  Data  Extraction  Analysis  and  Reduction  (GeDEAR)  Framework 

-  Cooperative  Communication  Control  Core  Engagement  (4CE)  framework 

-  Littoral  Combat  Ship  Surface  VNforfare  Mssion  Package  (LCS  SUW IVP) 
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Surface  Warfare  Centers:  Achievements  of  Success  Examples 


♦  Achievements 

-  Delivery  of  reliable,  maintainable,  scalable  and  reusable  architectures, 
design,  and  code  that  provide  multi -platform  and/or  multi-system 
capability 

-  Integration  of  a  nix  of  legacy  components,  new  Ctornmerd al -Off-The- 
Shelf  (COTS;  i  J.JUI  id  its,  di  iu  yuva  i  h  i  id  il  engineer-  developed 
reusable  architectures  and  components,  while  maintaining  Information 
Assurance  (IA) 

-  Incorporation  of  complex,  real-time,  safety  critical  functional 
requirements  and  the  associated  challenging  Key  Performance 
Parameters  (KPPS) 

-  Continuation  and  growth  of  government  corporate  knowledge  and  control 
of  the  system  architecture,  design,  and  technology 

-  Government  applied  technical  expertise  with  current  and  emerging 
system  and  software  technologies,  methodologies,  processes,  and  tods 

-  Delivery  of  these  systems  on  schedule  and  within  budget 
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TTWCS  Success  Example 

Integrated  Government  and  Industry  Development  Team 


External 

Communications 
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SATCOM 


GPS 


Operational 
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and  Reporting 
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National 

Imagery  Sources 
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TTWCS  Success  Example 

Multi -Platform  Capability 


Tl  CONDEROGA  (CG) 

22  Platforms 
•  MK  41  VLS 


SURFACE 


ARLEIGH  BURKE  (DDG) 


62  Platforms 
•  MK  41  VLS 

SUBMARI NE 


ZUMWALT  (DDG  1000) 

3  Platforms  (future) 

•  MK  57  VLS 


LOS  ANGELES  688 


SEAWOLF 


46  Platforms 
•  CLS/TTL 


UK 


3  Platforms 
•  TTL  Only 


TRAFALGAR 

7  Platforms 
•  TTL  Only 


ASTUTE 

3  Platforms  (1  additional  being  built) 
•  TTL  Only 


SSGN  VIRGINIA  Class 


4  Platforms  5  Platforms 

•  CLS  (MAC)  •  CLS/TTL 

•  7  more  VA  platforms  coming 

TTWCS  Variants: 

•  V4  Deployed 

•  V5.3.X  Deployed 

•  V5.4.0  In-Development  (System Test  Phase  FBI) 

•  V5.4.1  In-Development  (Inc2  CDR  next  Major  Mlestone) 
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Tomahawk  OA  multi-platform  capability 


Objects 


Platform  Launcher  Unique  Objects 
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Multi -System  Reusable  Component  Data  Extraction  and  Analysis 


GeDEAR  Generic  Data  Extraction,  Analysis  and  Reduction  Framework: 
Successfully  utilized  by  several  systems: 

-Tactical  Tomahawk  V\feapon  Control  System  (TTWZS) 

-Shipboard  Protection  System  (SPS) 

-  Advanced  Multi-configuration  Environment  Simulator  (AIVES) 

-  Littoral  Combat  Ship  (LCS)  Surface  Warfare  IVission  Package  (SVWP) 
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GeDEAR  Success  Example 

Reusable  Component 


♦  Generic  Data  Extraction,  Analysis,  and  Reduction  Framework  (GeDEAR) 

-  Allows  for  integration  of  a  software-based  data  extraction  capability  with  the  minimum  of 
cost  or  schedule 

-  Works  across  many  different  data  formats,  interfaces,  platforms,  operating  systems 

-  Provides  a  foundation  for  common  data  extraction,  reduction  and  analysis  tools 

-  Freely  available  on  forge.rril 

♦  GeDEAR  framework  consists  of  a  set  of  tods  for  addi  ng  data  extraction,  reduction, 
and  analysis  capability  to  a  software  system 

-  No  dependencies  within  tod  set 

-  Users  only  use  the  tods  they  need 

-  Capabilities  expanded  through  the  use  of  user-provided  plugins 

♦  GeDEAR  quickly  and  easily  integrated  into  systems 

-  Tactical  Tomahawk  VNfeapon  Contrd  System  (TTWCS)  —  4  week  effort 

-  Shipboard  Protection  System  (SPS)  —  3  month  effort 

-  Advanced  Multi-configuration  Environment  Simulator  (AIVES)  -  1  month  effort 

-  Uttoral  Combat  Ship  (LCS)  Surface  \Aforfare  IVIssion  Package  (SUWVP)  —  1  month  effort 


11 
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4CE  Success  Example 

Current  Rapid  Integration  Effort 


Gunslinger  FSEP 

17  DEVELOPERS 


Wolf  Pack  NEO 

11  DEVELOPERS 


GunPACS 


Command  and 
Control  Module 


4CE  COMMON  ARCHITECTURE 


Platform  X 
Widget 
A 


Presentation  Layer 
Platform  X 
Widget 
B 


Platform  y 
Widget 
C 


£ 


Platform  z 
Widget 
D 


O 


Middle  Layer 
Common  Interfaces 


FT. 


Hardware  Layer 


£ 


Plug-In  Framework 
Platform  X 
PLUG-ln 
Sensor  A 


Platform  Y 
PLUG-ln 
Sensor  B 


Easily  integrate  new  sensors  or  weapons  due  to: 


4  DEVELOPERS 


-  3  Tiered  architecture  with  common  interfaces  between  tiers 

-  Unique  hardware  interfaces  changes  isolated  to  small  plug-ins. 


Achieved  Goals:  Rapid  Development  and  delivery  (months  vs.  years),  high  quality  and  reliable 
Whrfighter  systems,  non-proprietary  systems,  government  developed  /  controlled  architecture 

GA Achievements:  Scalable,  reusable,  maintainable,  modular. 
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LCS  Background 


♦ 


LCS  IVSssion  Areas 

-  Counter  threats 

★  Littoral  mine,  Submarine,  Surface 

-  Assure  maritime  access  for  Joint  forces 

-  Achieved  by 

★  Modular  mission  packages  to  tailor  and 
optimize  the  ship  for  one  of  these  mission  areas  at  a  time 


USS  Independence  (LCS  2) 


USS  Freedom  (LCS  1) 


♦  Approach 

-  Innovative  design  for 

★  Modularity 

★  Rapidly  install  interchangeable  mission  packages  onto  the  seaframe 

♦  Precepts 


-  Accelerated  acquisition 

-  IVSni mum  crewing 

-  Cost  reductions 

-  SysterrYsoftware  reuse 
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LCS  SLW/l/f3  Success  Example 

LCS  SUWIVR  Description 


♦  LCS  Surface  \Aferfare  (SUW)  IVission  Package  (MP) 

-  Incrementally  fielded 

-  Provides  SUW focused  mission 


-  NSVNCOD-  technical  design  agent 

★  Provide  overall  systems  engineering,  development  and 
conduct/  coordination  of: 

»  Modularized  Gun  IVission  Module  (GMM) 

»  IVission  Package  Application  Software  (IVPAS) 

»  Command  &  Control  and  integration  interface  between 
and  the  ship’s  Combat  Management  System  (CMS) 

★  Employed  Prototype  process,  due  to: 

»  Accelerated  nature  of  LCS  acquisition 
»  Re  uired  com  orient  desi  ns  had  not  been  established 


Mission  Package  Application  Software  (MPAS)  hosted  on  the 
Mission  Package  Computing  Environment  (MPCE) 

Jy  #  4 — 

M 

1 

— - 
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LCS  SUWIVF*  Success  Example 

NSWCDD  Expertise 


♦  NSV\ODD  tenets  that  allowed  work  to  be  done  successfully 

-  A  defined  organizational  process  for  software  development, 
integration,  testing,  configuration  management  and  quality 
assurance 

-  A  software  (SW)/hardware  (HW)  element  and  integrated  test 
approach 

-  A  SUW IVPAS  Team  that  levera  edex  erienced  ersonnel 

V/  I  M  ' 

processes,  and  software  reuse  from  the  SQQ-89,  TOMAHAVNK, 
and  MK-160  programs  already  being  supported  at  NSW3DD. 
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Testing 


♦  IVRAS  Test  environment  at  NS\NC  Dahlgren 

-  Used  for  End-tc-End,  Hardware  in  the  Loop  (HIL),  live-fire  test 
events  of  the  complete  SUW  MP  system  prior  to  shipboard  testing 

-  Risk  mitigation  and  provides  excellent  software  quality  indicators 
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Summary 


♦  MPAS  development  and  testing  at  NSWCDD  has  proven  the  concept 
of  a  government  led  and  developed  effort 

-  Guided  by  incremental  processes  supporting  accelerated  schedule  and  rapid 
prototype  approach 

♦  Navy  laboratory  team  brought  to  this  effort: 

Co-located  software  and  hardware  developers 
V\fell  defined  processes 
Reuse  software  expertise 
VMthout  restrictive  contractual  barriers 


Congressman  Rob  Wittman  (R-VA-1):  “LCS  is  the  future  of  shallow  water  defense, . .  .Because  (of 
Dahl  ren  e  orts  the  Nav  will  be  armed  with  the  best  acka  e  available  or  littoral  war  are  and  ou  have 

^  r  «/«/  ^  J.  •/  •/  ^ 

made  this  happen  on  time  and  on  budget.  ”  SUW MP  Rollout,  July  2008 


Unclassified 


Distribution  Statement  A  Approved  for  public  release;  distribution  is  unlimited 


17 


In-house  Applied  Software  Expertise 


Maintaining  government  expertise  only  at  the  higher 
levels  of  System  abstraction  is  insufficient  to  improve 
software  intensive  system  acquisition 


Government  must  maintain  hands-on  applied  expertise  with 
rapidly  evolving  software  technologies  and  methodologies 
•  Required  for  successful  sw  cost,  schedule 
and  technical  performance  control 

Current  typical  software  system  acquisition  approach 
utilizes  government  sw  engineers  primarily  as  reviewers  but 
not  developers 
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Recommendation 

Utilize  Alternative  Software  System  Acquisition  Approach 


♦  Utilize  Government  in-house  Software  Expertise 

♦  To  provide 

-  Delivery  of  reliable,  maintainable,  scalable  and  reusable  architectures, 
design,  and  code  that  provide  multi-platform  and/or  multi-system  capability 

-  Integration  of  a  mix  of  legacy  components,  new  Commerd al -Off-The-Shelf 
(COTS)  components,  and  government  engineer-  developed  reusable 
architectures  and  components,  while  maintaining  Information  Assurance 

-  Incor  oration  of  com  lex,  real-time,  safet  critical  functional  re  uirements 
and  the  associated  challenging  Key  Performance  Parameters  (KPPs) 

-  Continuation  and  growth  of  government  corporate  knowledge  and  control  of 
the  system  architecture,  design,  and  technology 

-  Government  applied  technical  expertise  with  current  and  emerging  system 
and  software  technologies,  methodologies,  processes,  and  tods 

-  Delivery  of  these  systems  on  schedule  and  within  budget 
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Alternative  SW  Acquisition  Approach 
Keys  to  Success 


♦  Common  set  of  industry  &  government  processes  and 
expectations 

♦  VNfeil  defined,  documented  ana  maintained: 

-  Roles  and  responsibilities 

-  System  development  processes  and  metrics 

-  Cost,  schedule,  and  performance  expectations 

-  Integrated  Master  Schedule  (IMS) 

-  Interdependency  products  and  associated  delivery  dates 

-  Risk  management 

♦  Proactive  integrated  management  of  cost,  schedule  and 
performance 

♦  Government  test  team  is  independent  from  the 
development  team 

♦  IVEIestone  reviews  that  include  independent  competency 
experts 

♦  Frequent  (daily)  and  structured  team  communication 
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Way  Ahead 


♦  Apply  lessons  learned  from  successful  utilization  of  in- 
house  expertise 


♦  Program  Office  leaders  work  with  VNferfare  Center 
leaders  to  improve  utilization  of  in-house  expertise  and 
fadilities 
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In-House  Software  expertise 
Summary  /  Benefits 


♦  Government  Program  Offices 

-  Improved  Technology,  Cost,  and  Schedule  Estimates  and  Assessments 

-  Increased  and  maintained  corporate  knowledge 

-  Increased  acquisition  leverage  and  flexibility 

♦  Industry 

-  Improved  proposal  assessments  (smarter  partner,  not  just  lowest  bid  wins) 

-  Reduced  risk  (smarter  partner,  improved  requirements,  government 
accountability) 

-  More  profit  (less  dollars  on  rework  and  increased  system  production) 

♦  VNferfighter 

-  Faster  receipt  of  capabilities 

-  Increased  capabilities 

-  Higher  quality  and  more  reliable  systems 


“In  order  to  acquire  the  DON  platforms  and  weapons  systems  in  a  responsible  manner,  it  is  imperative  the  DoN 
maintain  technical  domain  expertise  at  all  levels  of  the  acquisition  infrastructure” 

-  D.  Writer:  SECNAV  Memo  Dated  10  Oct  08 
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BACKUP 
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References:  Need  for  in-house  expertise 


REFERENCES: 

DoD/Navy  Leadership  recognizes  the  need  to  reconstiture  government  in-house  expertise 

DATE 

REPORT  /  STUDY  /  MEMORANDUM  /  POLICY 

AUTHOR /SPONSOR 

KEY  QUOTES  /  POINTS  /  METRICS 

OCT  10 

SECDEF  MEMO: 

SECDEF 

"In  order  to  acquire  DON  platforms  and  weapons  systems  in  a  responsible  manner,  it  is 

2008 

Department  of  the  Navy  Acquisition 

Donald.  C.  Winter 

mperative  the  DON  maintain  technical  domain  expertise  at  all  levels  of  the  acquisition 
nfrastructure." 

"This  combination  of  personnel  reductions  and  reduced  RDT&E  has  seriously  eroded  the 
Department's  domain  knowledge  and  produced  an  over-reliance  on  contractors  to  perform  core 
n-house  technical  functions.  This  environment  has  lead  to  outsourcing  the  "hands-on"  work  that 
s  needed  in-house,  to  acquire  the  Nations  best  science  and  engineering  talent  and  to  equip  them 
to  meet  the  challenges  of  the  future  Navy." 

"The  fraction  of  RDT&E  funding  at  each  warfare  Center  and  Laboratory  should  be  maintained  at  a 
evel  sufficient  to  develop  and  sustain  the  needed  technical  capabilities  of  the  DON". 

NOV  07 

Senators  Levin  and  McCain  letter  to  SECDEF 

Senator 

Highlights  the  need  for  government  in-house  technical  expertise  in  the  acquisition  workforce, 

2008 

John  McCain 

especially  in  the  technical  and  business  domain 

NOV  04 

ASN/RDA  MEMO:  Meeting  of  the  Navy  Laboratory/Center 

ASN/RDA  PCD 

"...strategic  imperatives  that  1  have  received  from  the  ASN(RDA&A)  and  SECNAV..." 

2008 

Competency  Group 

James  E.  Thomsen 

STRATEGIC  OBJECTIVE  1:  Reverse  the  over-reliance  on  contractors  performing  core  Navy 
acquisition  functions. 

STRATEGIC  OBJECTIVE  2:  Stewardship  of  the  Navy's  Laboraties  and  Warfare  Centers  to 
ensure  long  term  health  and  effectiveness. 

STRATEGIC  OBJECTIVE  4:  Identify  and  develop  skilled  Program  Managers  and  their  successors 

DEC  05 

ASN/RDA  MEMO: 

ASN/RDA  PCD 

"1  expect  growth  in  the  organic  acquisition  workforce,  largely  offset  by  a  corresponding  decrease 

2008 

Strategy  to  Balance  Acquisition  In-house  and  Contractor  Support 
Capabilities 

James  E.  Thomsen 

n  outsourced  core  acquisition  (technical  and  business)  functions.  1  request  hat  each 
PEO/SYSCOM  team  submit  a  time-phased  strategy  to  increase  acquisition  organic  capabilities  by 
reducing  dependence  on  outsourced  core  acquisition  functions." 
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References;  need  for  in-house  expertise  (cont’d) 


MAY 

2008 

Report  of  the  Defense  Science  Board  (DSB)  Task  Force  on 
Developmental  Test  and  Evaluation 

Office  of  the  Under  Secretary 
of  Defense  for  Acquisition, 
Technology  and  Logistics 

"  In  recent  years,  there  has  been  a  dramatic  increase  in  the  numbers  of  systems  not 
meeting  suitability  requirements  during  IOT&E"." 

"there  was  a  loss  of  a  large  number  of  the  most  experienced  management  and 
technical  personnel  ...without  an  adequate  replacement  pipeline" 

"changes  in  developmental  test  and  evaluation  alone  could  not  remedy  poor 
ro  ram  formulation". 

"sequential  workforce  cuts  in  the  last  ten  years  had  a  significant  adverse  impact  on 
the  DOD  acquisition  capability".  "A  significant  amount  of  developmental  testing  is 
currently  performed  without  needed  degree  of  government  involvement  or  oversight" 

FEB 

Report  to  Congressional  Committees  Best  Practices: 

Government  Accounting 

Analyzed  1 1  major  DOD  weapon  Systems. 

2008 

Increased  focus  on  requirements  and  oversight  needed  to 
improve  DODs  Acquisition  Environment  and  weapon  System 
Quality  (GAO-08294) 

Office  (GAO) 

"defense  contractors  poor  practices  for  system  engineering  activities  as  well  as 
manufacturing  and  supplier  quality  problems"  contributed  to  significant  failures  wit 
regards  to  cost,  schedule  and  technical  performance. 

DOD  needs  to  adopt  a  knowledge  based  acquisition  approach. ..high  levels  of 
knowledge  must  be  demonstrated  at  critical  decision  points  in  the  product 
development  process 

2007 

ASN/RDA  Software  Process  Improvement  Initiative  (SPII) 

ASN/RDA 

Assessed  numerous  previously  existing  DOD/Navy  studies  and  reports;  and  found 

2008 

Software  Acquisition  Management  (SAM)  Focus  Team  "As- 
Is"  and  To-Be"  State  Reports. 

Chief  Engineer 

the  following  7  common  SW  Intensive  System  Acquisition  management  problems: 
Lack  of  effective  acquisition  management 

Immature  acquirer  (program  offices) 

Ineffective  requirements  management 

High  personnel  turnover  in  the  acquiring  organizations 

Unrealistic  Cost  and  Schedule  Estimates 

Ineffective  utilization  of  EVMS  for  SW 

Failure  to  take  advantage  of  lessons  learned 

To-Be"  report  recommendations  for  each  of  the  7  critical  problems  ALL  include 
requiring  the  government  to  train  and  better  utilize  Subject  Matter  Experts  (SMEs). 
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References;  need  for  in-house  expertise  (cont’d) 


SEPT 

2009 


Mr.  James  Thomsen  (ASN/RDA  PCD)  presentation  at  the  NSWCDD 
opening  ceremony  for  the  Directed  Energy  Center 


(ASN/RDA  PCD) 


Raesons  why  the  warfare  Centers  must  continue  to  exist: 

1 .  Government  Smart  Buyer. 

LSI  activities  should  be  conducted  by  Warfare  Centers.  WC  must  own  and  understand 
complex  systems  and  their  architectures.  We  must  understand  the  cost  and  technical  trade 
space  -  prior  to  industry  coming  on  board. 

2.  Technology  Expertise. 

We  must  understand  technologies;  especially  those  that  are  of  limited  interest  to  private 
ndustry.  Need  to  understand  how  to  apply  technology  to  warfare  systems. 

3.  Immediate  Response. 

Be  there  for  the  war  fighter/  and  in  crisis  situation  . 

4.  Corporate  Research  and  Development  memory. 

Maintain  expertise  and  knowledge  in  how  technology  has  been  applied  in  the  past  to  solve 
problems. 

5.  Provide  specialized  facilities. 

Maintain  specialized  facilities  that  Industry  can  not  invest  in  nor  maintain. 
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References:  Dr.  Ashton  Carter  Memo 

tntd  RecohuttcndtitUnts 


TARGET  AFFORDABILITY  AND  CONTROL  COST  GROWTH 

Affordability  is  a  requirement  and  will  be  treated  as  a  Key  Performance  Parameter. 

Utilize  Independent  “W\\  Cost"  as  well  as  'SHOULD  COST'  assessments. 

Eliminate  redundancies  within  war  fighter  (system)  portfolios 

Make  Production  rates  economical  (require  affordability  analysis) 

Shorten  program  ti  mel  i  nes. 

INCENT1VIZE  PRODUCTIVITY  AND  INNOVATION  IN  INDUSTRY 

Use  weighted  profit  guidelines. 

Provide  reward/incentive  strategy  in  acquisition  plan. 

Increase  utilization  of  Fixed  Price  Incentive  Firm  Target  contracts. 

Utilize  Progress  Payments  to  incentivize  performance. 

Reward  business  that  consistently  demonstrate  exce.  tional .  erformance. 

Reinvigorate  I  RAD  and  protect  the  defense  technology  base 

PROMOTE  REAL  COMPETITION 

Present  competition  strategy  at  each  milestone  review. 

Remove  obstacles  for  competitive  bidding. 

Require  OAand  set  rules  for  acquisition  of  technical  data  rights. 

Promote  utilization  of  small  business  (weighting  factor  in  solicitations). 

I  IN/PROVE  TRADECRAFT  IN  SERVICES  ACQUISITION 

Create  senior  manager  for  acquisition  of  services  responsible  for  governance 
Standardize  taxonomy  for  service  contracts 

Assist  users  of  services  to  define  requirements  and  prevent  requirements  creep. 

Increase  re-competes  of  knowledge  based  service  contracts. 

Unit  the  use  of  time  and  materials  and  award  fee  contracts  for  services. 

REDUCE  NON-PRODUCTIVE  PROCESSES  AND  BUREAUCRACY 

Reduce  the  number  of  OSD-level  review:  Focus  only  on  major  decision  points;  but  remain  cognizant  of  program  status  and  manage  risks. 
Eliminate  low-value-added  statutory  processes. 

Steam  line  Nun-McCurdy  review  process. 

Reduce  by  half  the  volume  and  cost  of  internal  and  congressional  reports. 

Reduce  non- value-added  overhead  imposed  on  industry 

Clarify  roles  and  responsibilities  of  DCMAand  DCAAto  reduce  duplication  of  effort  and  burdens  on  Industry. 

Increase  use  of  Forward  Pricing  Rate  Recommendations  to  reduce  Admin  costs. 


Unclassified 


Distribution  Statement  A  Approved  for  public  release;  distribution  is  unlimited 


Success  Example :  Roles  and  responsibilities 


Sponsor  and  Program  Office 

RFPs,  Funding,  and  Tasking  (SOW) 


Project  Lead  (EG.  Weapon  Control  System  X) 


Project  Management  IPT  Lead 


Dev  Team  Management  IPT 
Dev  Org’s  Project  Managers 


Technical  Direction  Activity 


Government  Leadership  and  Development  Oversight: 

Cost,  Schedule,  Technical  Performance  Planning  and  Tracking 
Risk  Management 


Technical 

Leads 


System 

Hardware 

Software 

Configuration 

System 

System 

Logistics  & 

Engineering 

Engineering 

Engineering 

Management 

Integration 

Test/Cert’s 

Training 

Government  and  Private  Industry  Development  Integrated  Product  Teams  (IPTs) 

-  Schedule,  Technical  Performance,  and  Risk  Management 

-  Development  effort  execution 

-  Metric  collection,  analysis,  process  improvement 


KEY 

Program  Office 


Government: 

Gov’t  &  Industry  IPTs 


Unclassified 


Distribution  Statement  A  Approved  for  public  release;  distribution  is  unlimited 


28 


Future  State  Challenge 

Maintaining  Government  Software  Expertise 


Gov’t  hands-on  software  development  is  required  to: 

•Maintain  expertise  with  the  latest  software  technologies 
•Attract  the  best  software  engineers 

•Serve  as  a  smart  buyer  and  successfully  team  with  industry 


Complexity 

and 

Level  of  Responsibility 


In-House  Software  Sub  ect  Matter  Ex  erts 


SOS  AND  COMPLEX  SYSTEM  LEVEL 

-Architect  and  Design  Complex  Systems 
-Assess  and/or  Provide  Technology  Approaches 
-Assess  and/or  Provide  Cost  and  schedule  Estimates 
-Serve  as  Software  Technical  Authority 


Segment  and  Component  Level 


Computer  SW  Configuration  Item  (CSCI)  Level 


l 

Technical  Assignment  | 
Loop-Back 


SW  Sub-Components 


Time 
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Future  State: 

Software  Technical  Challenges 


♦  Achieving  QDen  Architected  (OA)  software 

♦  I  ntegrati  ng  rapidly  evd  vi  ng  software  techndogies 

♦  Integrating  legacy  and  advanced  software  components 

♦  Achieving  Information  Assurance 

♦  Fully  meeting  functional  requirements 

♦  Maintaining  corporate  knowledge  and  contrd  of  the  software  components 


CURRENT:  Stove  Pipe 

Platform  X 


Non-Common 
System  &  SW  Growth 
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Future  State  Challenge 
Verifying  Open  Architecture  (OA) 

OA  characteristics  can  not  be  easily  verified  by  system  testing 

Applied  SW expertise  and  insight  into  design/code  is  required  to  assess  these  characteristics 


Gomposability 

The  System  Provides  Recombinant 
Components  that  can  be  Selected 
and  Assembled  in  Various  Combinations 
to  Satisfy  Specific  Requirements 


\ 


Reusability 


iC 


Maintainability 

The  Ease  VMth  VUiich  Maintenance  of 
a  Functional  Unit  can  be  Performed  in 
Accordance  VMth  Prescribed  Requirements 


Intero.  erabilit 

Ability  of  Two  or  More  Subsystem 
to  Exchange  Information  and  Utilize 
that  Information 


Ability  for  an  Artifact  to  Provide 
the  Same  Capability  in 
Multiple  Contexts 


Extensibility 

Ability  to  add  new  Capabilities  to  System 
Components,  or  to  add  Components 
and  Subsystems  to  a  System 


_ ¥ _ 

Open  Standards 

Standards  that  are  VMdely  Used, 
Consensus  Based,  Published  and 
Maintained  by  Recognized  Industry 
Standards  Organizations 


Diagram  Key 


is  Enabled  by 
is  Facilitated  by 


Modularity 

Partitioning  into  Dscrete,  Scalable, 
and  Self-Contained  Units  of  Functionality, 
VMth  \Nb\\  Defined  Interfaces 


*  Reference:  OA  Architectural  Principles  and  Guidelines  v  1.5.6, 2008,  IBM,  Eric  M.  Nelson,  Acquisition  Corrrnunity  VNfebsite  (ACC)  DAU  Navy  OA  VNfebsite 
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